1. Field
This disclosure relates to an environment employing persistent stores, more particularly to entries in a virtual space created in that environment.
2. Background
Sun Corporation developed Java™, a three-part distributed means for computing. The three parts of Java™ are the Java™ programming language, the Java Virtual Machine™ (JVM) and the Java™ platform.
The Java™ programming language is just that, a programming language with its own syntax, structures and procedures similar to all other languages. It is the language in which Java™ applications such as applets, servlets, and JavaBeans™ components are written. A unique part of the Java™ language, however, is that it does not compile into machine-readable code, as most other languages do. It compiles into byte codes. These byte codes are interpretable by the JVM.
The JVM is the Java™ interpreter. Java™ programs are portable, being in byte code format, but they are only portable to platforms to which a Java™ interpreter has been ported. Fortunately, JVMs are freely available for virtually all types of systems, from desktop systems running Windows, Unix or Macintosh, to cell phones. All of these are capable of being a Java™ platform.
A platform typically identifies a set of application programming interfaces (APIs) typically defined by the operating system. A programmer writing a program to run on a specific operating system such as Windows would use a different set of APIs than a programmer writing a program for the Macintosh operating system. However, the Java™ platform provides APIs that run on any operating system running the Java™ platform. In some respects, the Java™ platform is an intermediate platform between the Java™ code and the operating system. It allows programmer to write a program once and run it anywhere.
Because Java™ code may run on several different operating systems and several different devices, it would seem a logical extension of this would be to connect these all together. Jini serves as the framework to make those connections. Jini is a set of specifications that allows different services to discover each other on a network. The specifications also allow these services to participate in operations on this network; the network is sometimes referred to as a community. However, to avoid confusion in further discussions the network will be referred to as a network or a Jini™ community.
Jini™ focuses on services. A service may also be thought of as a service interface. For example, a certain device such as a server may present an interface to the outside world that is the device API. This API interface is a service. Because Jini™ is a distributed framework, there will be clients and servers. However, these clients and servers only care about the interfaces that allow them access to the other clients and servers. The client or server will know about the particular service API, but does not care about the implementation. For example, there may be a printer on the network. Another member of the network will know that there is a printer API but does not care what kind of printer it is. The print service will allow the member to send a print job to the service and will handle the translation of the print job to the specific API for the printer.
One example of a Jini™ service is JavaSpaces™. Simply, JavaSpaces™ define a persistent store. In terms of the above discussion, a client that wants to use JavaSpaces™ only needs to know the JavaSpaces™ API. The client does not need to know the specifics on what type of server upon which the JavaSpaces™ is implemented.
The Scalable Infrastructure™ system developed by Cisco® Systems provides a fully distributed, scalable infrastructure for communication system built upon Jini™ and JavaSpaces™ (Space). Devices and applications that wish to communicate with other members of a community or outside the community insert objects into the Space. The Space then publishes the presence of that object to subscribed members of the community. Double agents are capable of communicating with any desired protocols on one side and the Space protocol on the other. Non-space specific agents handle routing, administrative and other tasks, such as communication between Spaces and Communities.
However, there are limitations on the use of Spaces in such an application. Entries within a Space are not evolvable. Once the Virtual Machine within the Space implementation has downloaded the class for the entry, no further modifications are allowed. New fields cannot be added, nor current fields removed from entries once they are downloaded, unless the Virtual Machine is restarted. This limits the flexibility and applicability of both JavaSpaces™ and Scalable Infrastructure™ communication systems.